n 

o 
c 

in 



H 
O 



Please type a plus sign (+) inside this box -> 




UTILITY 
PATENT APPLICATION 
TRANSMITTAL 

(Only for new nonprovisional applications 
under 37 CFR 1.53(b)) 


Attorney Docket No. 


99RSS268 m^^S 


First Named Inventor 
or 

Application identifier 


DAVID C. BOIKE 


ADDRESS TO: 

Assistant Commissioner of Patents 
Box Patent Application 
Washington, DC 20231 


Title 


SYSTEM INTERFACE ABSTRACTION LAYER 


Express Mail No. 


EL357887246US 



APPLICATION ELEMENTS 

See MPEP chapter 600 concerning utility patent application contents 
1 • X Fee Transmittal Form TTO/SBM (submit in duplicate) 

2. X Specification [Total Pages: 31 1 

3. _X_ Drawing(s) (35 USC 113) [Total Sheets: JJ 

4. Oath or Declaration [Total Pages: ] 

a. Newly executed (original or copy) 

b. Copy from a prior application (37 CFR 1 63(d)) 

(for continuation/divisional with No. 1 7 completed) 

[Note No. 5 below] 
i. _ DELETION OF INVENTOR(S) 
Signed statement attached deleting 
inventor(s) named in the prior application, see 
37 CFR 1.63(d)(2) and 1.33(b). 

5. Incorporation By Reference (useable if No. 4b is 

checked) 

The entire disclosure of the prior application, from which a copy of 
the oath or declaration is supplied under No. 4b, is considered as 
being part of the disclosure of the accompanying application and is 
hereby incorporated by reference therein. 

6. Microfiche Computer Program (Appendix) 

7. Nucleotide and/or Amino Acid Sequence Submission 

(if applicable, all necessary) 

a. Computer Readable Copy 

b. Paper Copy (identical to computer copy) 

c. Statement verifying identity of above 

copies 



ACCOMPANYING APPLICATION PARTS 

8. Assignment Papers (cover sheet & document(s) 

Power of Attorney 

English Translation Document (if applicable) 



9. 
10. 
11. 



12. 



Information Disclosure 
Statement (IDS)/PTO-1449 

Copies of IDS Citations 

Preliminary Amendment 



13. X Return Receipt Postcard (Itemized) 

14. _ Small Entity Statement(s) 

Statement filed in prior application. Status still 

proper and desired 



15. 



16. 



Certified Copy of Priority Document(s) 
(if foreign priority is claimed) 

Other: 



17. If a CONTINUING APPLICATION, check appropriate blank and supply the requisite information: 
Continuation i 

Divisional 1 of prior application No.: / 

Continuation-in-part (CIP) I 



18. Correspondence Address 


Customer Number or Bar Code Label or 

22478 

(Insert Customer No. or Attach bar code label here) 


X Correspondence address below 


Name 


Attn: David R* Clonts 

AKIN, GUMP, STRAUSS, HAUER & FELD, L.L.P. 


Address 


711 Louisiana, Suite 1900 


City 


Houston 


State 


Texas 


Zip Code 


77002 


Country 


U.S.A. 


Telephone 


(713) 220-5800 


Fax 


(713) 236-0822 




044368.0191 HOUSTON 118559 vl 



U.S. EXPRESS MAIL NO. EL357887246US 



PATENT 



TN T HE TTTVITFX) STATF R PATENT AND TP REMARK OFFICE 

(Attorney Docket No.: 99RSS268) 

TITLE: 

SYSTEM INTERFACE ABSTRACTION LAYER 



TNVENTOR: 



David C. Boike 
133 County Road 1169 
Cullman, AL 35057 
Citizenship: U.S. Citizen 



ASSIGNEE: 
Conexant Systems, Inc. 
4311 Jamboree Road 
Newport Beach, CA 92660-3095 



-p.ERTIFICATF OF EXPRESS MAILING 
■ hprpbv certify that this correspondence is being deposited with the 



Express Mailinj 



(/Label No.: EL357887246US 




Rochelie M. Pleasant 



044368.0191 HOUSTON 114346.v4 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



(Attorney Docket No. : 99RSS268) 
SYSTEM INTERFACE ABSTRACTION LAYER 



TITLE: 



SPECIFICATION 
BACKGROUND 

1 . Field of the Invention 

The present invention generally relates to a driver architecture and, more particularly, 
to a system interface abstraction layer. 

2. Description of the Related Art 

One major issue for communications systems is support for peripheral devices. Most 
communications systems, from the low end to the high end, have an ever increasing array of 
possible peripheral devices such as modems, printers, plotters, fax machines and scanners. 
Not only new devices but new device types are frequently developed. Each specific type of 
device has its own memory, I/O and management requirements, and, often, two devices of the 
same type can have different requirements as well. In the face of this increasing complexity, 
much time and expense is expended by programmers and hardware designers to ensure that 
new devices and new device types are compatible with old devices and types. Often a new 
device may offer a feature that is simply not supported by the existing hardware and software, 
thus preventing the new device from fully utilizing all its features. 

Typically, a new peripheral device, a new class of peripheral devices, a new 
processing card or a new type of processor is integrated into a communications system with 
drivers that provide code necessary to send commands to and receive replies or data directly 
from the operating system. Much of the code necessary for integration duplicates older code 
written for other devices, classes, cards or processors. This duplication may even extend 
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across code for devices, classes, cards and processors, particularly if the code is designed to 
access commonly used features of an operating system or software module. 

One example of an attempt to deal with this issue is the Network Driver Interface 
Specification (NDIS) written by the Microsoft Corporation of Redmond, Washington. NDIS 
defines a common software module interface for a network protocol stack which provides for 
network communications, adapter drivers which provide media access control (MAC), and 
protocol managers which enable the protocol stack and the MAC to cooperate. NDIS allows 
Microsoft® Windows modules, which implement different connectionless protocol stacks 
such as TCP/IP and IPX/SPX, to access different network hardware types such as Ethernet 
and token ring in a uniform manner. NDIS enables these functions by implementing a NDIS 
miniport interface. 
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SUMMARY OF THE INVENTION 

Briefly, a communications system provides a system interface abstraction layer 
(SIAL) or system driver interface that eliminates operating system (OS) specific and platform 
specific semantics from communication paths between a driver and the rest of the 
5 communications system. Basic software messaging is thus simplified without changing 
either operating system or platform specific library functions. 

A software message may originate from internal or external driver entities. Each 
message source typically may have a unique set of semantics for communicating to a 
message destination or target module. The SIAL isolates the source of a software message 
ljjf from the OS. 

U Each unique path between a message source and a message destination can be 

referred to as a message channel or path. The SIAL serves as a set of function calls between 
i3 message sources and destination modules. The SIAL, which can be a layer of software 
y within a miniport driver, supports a plurality of messaging channels. 

j| The SIAL provides a message controller that is responsible for routing messages 

between various internal and external entities. The message controller includes a plurality of 
installable components with data conversion and command conversion routines for the 
plurality of messaging channels. Each installable component services a particular messaging 
channel. The SIAL also provides an operating system interface which provides OS functions 

20 for the plurality of installable components. Finally, the SIAL provides a platform interface 
that supplies platform specific functions to the plurality of installable components. 

By employing such a SIAL, software modules and drivers can employ a standard 
interface and thus be interchanged and updated or modified in less time using fewer 
programming resources. In addition, software modules and drivers can be ported to a 

25 different OS or platform with increased efficiency. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



A better understanding of the present invention can be obtained when the following 
detailed description of the preferred embodiment is considered in conjunction with the 
following drawings, in which: 

Figure 1 is a block diagram of a exemplary communications card which can 
implement a system interface abstraction layer (SIAL) of the disclosed embodiment; 

Figure 2a is a block diagram illustrating a typical system/driver architecture according 
to the Network Device Interface Specification (NDIS); 

Figure 2b is a block diagram of an exemplary system/driver architecture supporting 
the NDIS of Figure 2a and the SIAL of the disclosed embodiment; and 

Figure 3 is a block diagram illustrating the SIAL of Figure 2b in more detail. 
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DETAILED DESCRIPTION OF PREFERRED EMBODIMENT 



The following commonly-assigned patent application is hereby incorporated by 
reference as if set forth in its entirety: 

U.S. Patent Application, bearing Attorney Docket No. 99RSS268, entitled "CHIP 
5 ABSTRACTION LAYER" filed concurrently. 

Turning now to Figure 1, illustrated is an exemplary communications card or system 
C which may utilize the techniques of the disclosed embodiment as implemented in software 
on a computing system. In the alternative, the communications card may include an 
embedded operating system which implements the techniques of the disclosed embodiment. 
The communications card C includes a line driver 104, a analog front end (AFE) 106 and a 
U data pump 108. The line driver 104 is coupled to the AFE 106, and the AFE 106 is coupled 
C to the data pump 108. The line driver 104, the AFE 106 and the data pump 108 are each 
O coupled to a peripheral component interconnect (PCI) bus controller 110. The 
E f communications card C can be a variety of communications devices such as a network 
IS interface card (NIC) or a modem. 

It should be understood that the communications card C is used for illustration and 
that a number of configurations with less, more or different components are possible. The 
term communications card should generally be understood to include any card with modem 
or similar communication capability. 
20 Turning now to Figure 2a ? illustrated is the Network Driver Interface Specification 

(NDIS) "miniport" architecture model published by the Microsoft Corporation. Although the 
techniques of a disclosed embodiment are shown as implemented on a Windows® operating 
system (OS) and a NDIS platform, it should be noted that the specific OS and platform are 
not limiting and the disclosed techniques can be extended to other OSs and platforms. 
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The communications card C supports a user mode 221 and a kernel mode 223 to 
interface with an operating system of the card C. User mode 221 and the kernel mode 223 
are generally understood in the art. The user mode 221 generally refers to low priority OS 
functions and the kernel mode generally refers to high priority OS functions. Included in the 
5 user mode 221 are user applications 201, a control panel 203, a hardware input/output (I/O) 
library 205 and a windows subsystem 207. The windows subsystem 207 can be any software 
entity in the Windows® architecture. One example of a windows subsystem 207 is a NDIS 
local area network (LAN). The kernel mode 223 includes a NDIS module (or other network 
driver interface) 211. The NDIS module 211 can be viewed as a combination of a static 
ffl library 213 and a dynamic messaging path 215. Design and use of NDIS is generally 
;P understood in the art. A wide area network/local area network (WAN/LAN) minport driver 
217 provides access to the communications card C. The design and use of miniport drivers 
r i are also understood in the art. 

q The NDIS architecture provides software modules a way to access the 

15 communications card C regardless of the network type. In other words, a software module 
^3 that communicates with the communications card C is not required to know the specific 
protocol of a network such as Ethernet or token ring. The NDIS module 21 1 abstracts the 
details of the network through the static library 213 and the dynamic messaging 215. 

Turning now to Figure 2b, illustrated is an exemplary system/driver architecture 
20 providing a system interface abstraction layer (SIAL) 251 which can be implemented by a 
driver such as the miniport driver 217 to access the communications card C. In this example, 
the NDIS 21 1 runs in a kernel mode 225. The SIAL 251 is a layer of software which is part 
of the miniport driver 217 and can be accessed from the NDIS 211. The SIAL 251 can 
support multiple OS and platform specific message channels for internal driver entities of the 
25 communications card C. The SIAL 251 thus provides a standard set of semantics to internal 
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driver entities for communicating through specific message channels. Messages can be 
routed between an internal driver entities and external driver entities by the SIAL 251. 
Messages also can be routed between internal driver entities by the SIAL 25 1 . In a disclosed 
embodiment, the internal driver entities are miniport driver entities and the external entities 
5 are non-miniport entities. 

Turning now to Figure 3, illustrated is SIAL 251 first introduced in Figure 2b. The 
SIAL 251 includes an external interface 351, an internal interface 353 and a platform 
interface 324. As discussed above in conjunction with Figure 2b, the SIAL 251 is here 
implemented as a software layer within the miniport driver 217. 
B3 The external interface 351 includes an OS interface 312 and interface functions 314. 

4- The external interface 351 handles the tasks associated with sending and receiving a message 
;f 331 to and from an external, or system, entity 301. The external interface 351 handles both 
f'4 the semantics and procedures specific to a platform or an OS. The OS interface 312 is 
Q responsible for direct communication to external driver entities such as the system entity 301 
M which employs software messaging. The OS interface 312 handles semantics of external 
^3 driver entities such as external miniport modules described in more detail below. The OS 
interface 312 can access standard driver library functions of internal driver functions as 
described below in conjunction with the external interface 351. In addition, multiple OS 
interfaces (not shown) may be defined to communicate with multiple external driver entities. 
20 The internal interface 353 handles the semantics of sending and receiving a message 

335 to and from an internal driver entity 303. The internal interface 353 includes a message 
controller 316 and one or more installable components, an installable component 0 321, an 
installable component 1 322 and so on through an installable component N 323. The 
message controller 316 routes messages between each of the installable components 321, 322 
25 and 323 and driver entities. As the name implies, the installable components 321, 322 and 
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323 are added and removed from the message controller 316 depending upon the specific 
software entities that seek to use the SIAL 251. The internal driver entity 303 sends and 
receives messages such as the message 335 directly from a corresponding installable 
component, in this example installable component 0 321. 
5 The internal driver entity 303 both sends and receives messages directly to and from 

the message controller 316 by employing a predetermined set of functions pointers. During 
initialization, pointer to functions 337 are passed from the interface functions 314 to a 
corresponding installable component, in this example, installable component 1 322. Once the 
function pointers 337 have been passed to an installable component such as installable 
1HJ component 0 321, the installable component 0 321 can communicate with either the OS 
4« interface 351 or the internal entity 303 in any order. The functions represented by the 
P function pointers 337 are described in detail below. An internal driver entity 303 which is 
™ able to utilize the SIAL 25 1 can be an internal "miniport" module 347. 

* n In this example, the OS interface 312 interfaces with a Windows® OS 25. Additional 

|J OS interfaces may be added or substituted to provide an interface between multiple external 
C) driver entities and other OSs such as Solaris® developed by Sun Microsystems of Mountain 
View, California, LINUX written by Linus Torvalds or OS/2 developed by IBM Corporation 
of Armonk, New York. The OS interface 312 supplies pointers to OS specific interface 
functions 314 which form part of the installable components 321, 322 and 323. The platform 
20 interface 324 provides pointers to platform specific functions to the message controller 316. 
Examples of platform specific functionality include setup/control 339 and operations that 
occur at driver initialization time. In a manner similar to the OS interface 312, platform 
specific modules can be added, removed or interchanged depending upon the specific 
platform of the communications card C. In this way, the SIAL 251 eliminates the need to 
25 change internal modules defining the miniport driver 217 when an external interface changes. 
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In other words, the SIAL 251 hides or isolates the requirements or semantics of external 
driver entities from internal driver entities of the miniport driver 217. 

The platform interface 324 includes public interfaces for platform specific operations 
such as initialization, startup, shutdown and linking well-known handles to an instance of the 
5 SIAL 251. The platform interface 324 can encapsulate operations that are necessary to 
establish or destroy the external interface. Specific platforms such as a NDIS local area 
network (LAN) or a Win32 Driver Model (WDN) published by Microsoft may require 
specialized operations for the creation of the external interface. For example, in the case of 
NDIS, the driver uses a library function NdisMRegisterDevice to create device objects. In 
IDj the alternative, a WDM driver uses a combination of an IoCreateDevice function and an 

IoRegisterDevicelnterface function which are functions well known in the art. 
;f The system entity 301, running in the OS 25, can send the message 331 to the OS 

M interface 312 which interfaces to the OS 25. The OS interface 312 processes the message 
O 331 and sends the result as message 333 to the installable component 0 321 which 
IS corresponds to the internal entity 303 with which the system entity 301 is attempting to 
G communicate. In this way, the message 331 is independent from both the OS 25 and the 
specific platform of the computing system S. A message from the internal entity 303 follows 
the same path in the other direction. In addition, internal entities can utilize the SIAL 251 to 
communicate with each other. 
20 Messages 331, 333 and 335 contain a header section or portion and a variable length 

information section or portion. The header portion communicates routing information that 
enables the message controller 316 to move information between various entities such as the 
system entity 301 and the internal entity 303. The information portion contains the data that 
is specific to the action the target module, in this example the system entity 301, is expected 
25 to perform. The information section is opaque or masked to the message controller 316, 
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whereas the header is considered opaque or masked to the internal entity 303. The 
information section does not contain data that is not directly related to the target action. 
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The message header is here shown as a 32-bit value. The format of the message 



header is defined by the following header table: 



Bit 


Name 


Value 


Description 


0-15 


Event 


Enum * 


Unique Event for a specified channel 


16- 
23 


Channel 


Enum * 


Message Channel Identifier 


24- 
30 


Type 


Enum * 


Specifies a set of Message Controller 316 algorithms for a 
channel. 




TypeJData 


0 


Data Buffer does not contain embedded commands 




TypeCommand 


1 


Buffer contains embedded commands. This requires a set 
of external functions to encode, decode, and store 
commands. 


31 


In_Order 


Binary 


Indicates messages will be passed to internal entities 
based on the increasing or decreasing value of Module Id. 






0 


Increasing Order 






1 


Decreasing Order 



^rf * 0 relative enumeration 



=;T An explanation of data types employed in the techniques of the disclosed embodiment 

15 is helpful to an understanding of data structures and functions described below. One skilled 

C3 in the art would understand the following type definitions. A CHAN COMMAND T data 

C type is defined as follows: 
j!r typedef struct 

W * union COMMANDTJ 

^ { 

DWORD Command; 
struct 

{ 

15 DWORD Event; 

DWORD Channel 8; 
DWORD Type 8; 
} Element; 

}; 

20 } CH AN COMM AND_T . 
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A FN_SYS_RECEIVE_HANDLER pointer to a function data type is defined as 
follows: 

typedef 

NTSTATUS (* FN_SYS_RECEIVE_HANDLER) ( 

5 VOID * UserContext; 

CHAR *Buffer; 

DWORD Length 

)• 

A SYS_IF_MODULE_ID_T data type is defined as follows: 

10 typedef enum 

{ 

IF_MODULE_ID_START = 0, 

IF_SYS_MGMT_ID = IF_MODULE_ID_START, 

IF_CHIPAL_ID, 
IS IF_DBG_TERM_ID, 
■3 IF_MODULE_ID_END 
l : } SYS_IF_MODULE_ID_T. 

H A DEVICE J^HANNELJT data type is defined as follows: 

typedef struct 
25 { 

D LIST_ENTRY pMessage[MAX_CHAN_MESS AGES] ; 

3 DWORD MaxMessages; 

~y DEVICEOBJECT pChannelDeviceObj ect; 

H } DEVICECHANNELT. 

21 A DEVICECHANNELT pointer to a function data type is defined as follows: 

typedef 

NTSTSTUS (* W_QUERY_ESfFORMATION HANDLER) ( 
IN VOID * MiniportAdapterContext, 
IN ULONG Oid, 
30 IN PVOID InformationBuffer, 

IN ULONG InformationBufferLength, 
OUT PULONG BytesWritten, 
OUT PULONG BytesNeeded 

). 

35 The message header is described as the user defined data type - 

CHAN_COMMAND_T. This type is used by the message controller 316. Internal driver 
modules view the header as the opaque value SYS_MESS JT. The multiple views of the 
same data are intended to help enforce the architecture implemented by the entire SIAL 251. 
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The contents of the information section are not defined for the message controller 
316. The information is an opaque data set transported across a specified channel. An 
internal or external entity includes a buffer to store information. The property of the buffer 
understood by the message controller 3 16 is the overall length in bytes. 

An internal interface 353 of the SIAL 251 includes a SmSysIfAddMessageHandler 
module, a SmSysIfGetHandle module, a SmSysIfSendMessage module and a 
SmSysIffiroadcastMessage module, all described in more detail below. The modules of the 
internal interface, or "internal modules," that process a specified message indicate the amount 
of data they expect to modify. This value is known as the Buffer Length. When the message 
controller 316 receives a new message from the external entity 301, the message controller 
316 ensures the new message contains the necessary storage space based upon a calculated 
sum of all Buffer Length requirements as indicated by all the internal modules of the SIAL 



The internal driver modules access the message controller 316 from the internal 
interface 353. The internal interface 353 provides a set of function calls that allow modules or 
entities to bind a function to a specified message, send messages to an external entity, or 
broadcast a message to all internal driver modules. 

The function, SmSysIfAddMessageHandler, is used to bind a call back function in an 
internal driver module to an occurrence of a message on specified message channel. The 
function includes the following parameters: 



251. 



DWORD 



VOID 



SYS MESS T 



* SysIfContext; 

MessageHeader; 

Length; 



FN SYS RECEIVE HANDLER 



ReceiveHandler; 



VOID 



* FunctionContext; 



SYS IF MODULE ID T 



Moduleld. 
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The SysIfContext parameter of a VOID pointer data type is a handle to an instance of 

the SIAL 25 L SysIfContext is provided as an output from the SmSysIfGetHandle function 

described below. Typically, there is one SysIfContext for each instance of a driver. The 

MessageHeader parameter of a SYSJMESS JT data type is an opaque message identifier that 

5 uniquely identifies a message and a message channel. The values of the MessageHeader 

parameter are defined above in the message header table. The Length parameter of a 

DWORD data type identifies the amount of data in an information buffer that an internal 

module can modify when the message controller 316 delivers a message. If an information 

buffer is not modified, then this value should be set to c 0\ The ReceiveHandler parameter of 

lO FN_SYS_RECEIVE_HANDLER data type is a pointer to a routine called by the message 

^ controller 316 when a new message is received. The FunctionContext parameter of VOID 

H pointer data type is an internal module context delivered by the message controller 316 as a 

parameter in the ReceiveHandler function call. The FunctionContext parameter is an opaque 

ri value to the message controller 316 but can be viewed by the internal driver modules. 

M Typically an internal module supplies a local context value in this argument. The Moduleld 

y3 parameter of SYS JF__MODULE_ID JT data type identifies a relative position of the internal 

driver module in relation to all other modules in the driver architecture. This value is used to 

create an ordered driver call stack. A typical usage is to create a data stack. Modules are 

placed in the data stack according to their Moduleld. 

20 The function, SmSysIfGetHandle, returns a context handle to the message controller 

316. One handle is associated with each instance of the miniport driver 217. The 

SmSysIfGetHandle module includes the following parameters: 

IN VOID * pThisAdapter; 

OUT VOID ** Handle. 

25 The pThisAdapter parameter of VOID pointer data type is a pointer to a global 

instance of a driver and is relative to the context of the internal driver module. The Handle 
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parameter of VOID pointer to pointer data type is a pointer to a pointer to the message 

controller 316 associated with the pThis Adapter context. 

The function, SmSysIfSendMessage, sends a message from an internal driver entity to 

an external entity. This function is used to communicate with other drivers or with the user 

5 applications 201 and includes the following parameters: 

VOID * SysIfContext; 

SYS_MESS_T MessageHeader; 

CHAR * Buffer; 

DWORD Length. 

10 The SysIfContext parameter of VOID pointer data type is a pointer to a handle to an 

■ =5 instance of the SIAL 251. This parameter is provided as an output from the 

>* SmSysIfGetHandle module. Typically, there is one SysIfContext for each instance of a 

u driver. The MessageHeader parameter of SYS_MESS_T data type is an opaque message 

^ identifier that uniquely identifies a message and a message channel The values of the 

15 MessageHeader parameter are defined in the message header table described above. The 

7^ Buffer parameter of a CHAR pointer data type is a pointer to a data area containing data to be 

,Jt transmitted across the message channel indicated by MessageHeader paramteter. The Length 

parameter of DWORD data type is the length in bytes of the data area pointed to by the 

Buffer parameter. 

20 The function, SmSysIfBoradCastMessage, sends a message from a single internal 

driver module to all other driver modules registered for a specific message. This function can 

be used to communicate a global driver event or to create a protocol stack within the miniport 

driver 217. The SmSysIfBoradCastMessage module includes the following parameters: 

VOID * SysIfContext; 

25 SYSJMESSJT MessageHeader; 

CHAR * Buffer; 

DWORD Length. 
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The SysIfContext parameter of VOID pointer data type is a handle to an instance of 
the SIAL 251. This is provided as an output from the SmSysIfGetHandle function. 
Typically, there is only a SysIfContext for each instance of the miniport driver 217. Again, 
the MessageHeader parameter of SYS _MESS_T data type is an opaque message identifier 
5 that uniquely identifies a message and a message channel. The values of the MessageHeader 
parameter are defined in the message header table described above. The Buffer parameter of 
CHAR pointer data type is a pointer to a data area containing data to be transmitted across the 
message channel indicated by MessageHeader parameter. The Length parameter of DWORD 
data type is the length in bytes of the data area pointed to by the Buffer parameter, 
itf The external interface of the SIAL 251 supports the following functions: a 

rP FNEXTERNALSENDHANDLER function, a FNADDMODULE function, a 
it FN_GET_HANDLER_LIST function and a SmSysIfSetDevice function. These functions 
r i are utilized by the message controller 316. 

p For each external entity such as the system entity 301, the format of a data message is 

t$ specific to that entity. Therefore, a translation may be necessary in order to communicate 
"0 software messages between modules or entities. The translation functions are here the 

responsibility of the external modules. 

The FN EXTERNAL SEND HANDLER function can perform translations and 

route a message from an internal driver enity to an external driver entity. This function is 
20 called by the internal interface function SmSysIfSendMessage. In the case where a message 

channel is being used to communicate internally within the miniport driver 217, this function 

is optional. The FN_EXTERNAL_SEND_HANDLER function includes the following 

parameters: 

IN PDEVICE J3B JECT pDeviceObj ; 

25 IN CHAR * Buffer; 

IN DWORD Length. 
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The pDeviceObj parameter of a PDEVICE_OBJECT data type is a pointer to an 

device object that describes a driver interface to the OS 25. Miniport drivers do not always 

supply the DEVICE_OBJECT as an input parameter to the miniport. Therefore, the message 

controller 316 maintains a global list of interfaces. This list is used to match various external 

5 handles to the device object pointed to by the pDeviceObj parameter. The Buffer parameter 

of CHAR pointer data type is a pointer to a data area containing data to be transmitted across 

to the external entity. The Length parameter of DWORD data type is the length in bytes of 

the data area pointed to by the Buffer parameter. 

The FNADDJTANDLER function associates a callback function with a unique 

ill message on a specified message channel and includes the following parameters: 

;P IN DEVICE_CHAKNEL_T * pChan; 

O IN CHAN COMMAND T Message; 

FfJ IN DWORD Length; 

Q IN FN_SYS_RECEIVE_HANDLER ReceiveHandler; 

|5 IN VOID * Context; 

f 3 . IN SYSJFJVfODULEJDJT Moduleld. 

SKI!? 

The pChan parameter of DEVICE_CHANNELjr pointer data type is a context 
pointer that describes the properties of a message channel within the message controller 316. 
The Message parameter of a CHAN_COMMAND_T data type uniquely identifies a message 

20 and a message channel. The values of the Message parameter are defined in the message 
header table described above. The Length parameter of DWORD data type indicates the 
number of bytes a callback function will return when a new message is received. This value 
can be '0' if the callback routine does not modify the message. The ReceiveHandler 
parameter of FNJSYS_RECEIVE_HANDLER data type is a callback function provided by 

25 an internal driver module. The callback function can be invoked when the message specified 
by the Message parameter is received from the message channel specified by the Message 
parameter. The Context parameter of VOID pointer data type is meaningful to an internal 
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driver module in that the parameter is returned to the ReceiveHandler routine when a new 
message arrives. The Moduleld parameter of SYS_IF_MODULE_IDJT data type can be 
used by the message controller 316 to determine a call order of an associated CallBack 
functions. Each message can be associated with multiple callback routines. In such a case, 
5 the order in which the CallBack routines are invoked may be significant. If so, the Moduleld 
parameter can be an integer that reflects the increasing order of a call tree. Otherwise, the 
value can be '0'. 

The FN_GET_HANDLERJLIST function can retrieve a callback function list from 
an external module associated with a specific message channel and includes the following 
lfip parameters: 

I : P IN DEVICE J3HANNELJT * pChan; 

£3 IN CHAN_COMMANDJT Message; 

Hj OUT LISTJENTRY ** ppMessageList 

T" The pChan parameter of DEVICECHANNELT pointer data type is a context 

i5 pointer that describes the properties of a message channel within the message controller 316. 
C3 As in other functions, the Message parameter of CHAN_COMMAND_T data type uniquely 
W identifies a message and a message channel. The values of the Message parameter are defined 

in the message header table described above. The ppMessageList parameter of a 

LISTENTRY pointer to pointer data type is a pointer to a pointer to the head of a callback 
20 function list. If an external module is unable to associate the message specified by the 

Message parameter to an external message, then this value can be '0'. 

The SmSysIflndicateNewMessage function can indicate that a new message is 

available from the system entity 301 and includes the following parameters: 

IN PDEVICEJDBJECT pDevice; 

25 IN DWORD ExternMessage; 

I_P CHAR * Buffer; 

IN DWORD Length. 
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The pDevice parameter of PDEVICEOBJECT data type is a pointer to a device 
object that describes a driver interface to the OS 25. Miniport drivers are not required to 
supply the device object as an input parameter to a miniport. Therefore, the message 
controller 316 maintains a global list of possible interfaces used to match various external 
5 handles to the device object.. The ExternMessage parameter of DWORD data type can 
indicate a specific message and message channel that is available. The Buffer parameter of 
CHAR pointer data type points to a data area containing the message from an external entity. 
The contents of the message are specific to an action or data that is being requested. The data 
area does not contain overhead information that is specific to a message channel. In the 

1® miniport driver 217, a final recipient of a message understands or modifies the data area 
pointed to by the Buffer parameter. The Length parameter of DWORD data type can contain 

?2 the length in bytes of the data area. 

q The SmSysIfSetDevice function can associate an external message channel with an 

O instance (context) of the miniport driver 217 and includes the following parameters: 

U IN PDEVICEJ3BJECT pDeviceObj; 

3 IN CHAN COMMAND ! Message; 

y 3 I__0 PDEVICE_OBJECT UserDevice. 

Like pDevice, the pDeviceObj parameter of PDEVICEOBJECT data type is a 

pointer to an object that describes a driver interface to the OS 25. The Message parameter of 

20 CHANCOMMANDT data type indicates a message channel that will be associated with a 

miniport context. The UserDevice parameter of PDEVICE_OBJECT data type is a handle as 

viewed from the external entity associated with the Message channel. In the minport driver 

217, the external entity is a NDIS adapter context. 

Exemplary public functions of the platform interface 324 include a SmWdmlflnit 

25 function, a SmWdmlfShutdown function, and a SmKernelLoadHandlers function. The 
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public function, SmWdmlflnit, creates an instance of the SIAL 251 and includes the 

following parameters: 

IN PDRIVER^OBJECT DriverObject; 

IN VOID * UserContext; 

5 IN PDEVICEJDBJECT PhysicalDeviceObject; 

IN PUNICODE_STRING RegistryPath; 

W_QUERY_INFORMATION_HANDLER QueryHandler. 

The DriverObject parameter of PDRIVEROBJECT data type is a miniport 

DriverObject used to create one or more device objects. Typically, there is one device object 

10 for each instance of the miniport driver 217. The UserContext parameter of VOID pointer 

O data type is a handle used to associate a pseudo global handle (NDIS adapter context) to the 

:? instance of the SIAL 251 being created. This allows other internal driver modules to 

fi determine the context of the SIAL 251 associated with a well-known driver handle by using 

S the SmSysIfGet Handle function. The PhysicalDeviceObject parameter of 

|f PDEVICEOBJECT data type is a physical device object for an instance of the miniport 

id driver 217. This is an optional parameter used by WDM drivers to create a WDM System 

^3 Interface. For the NDIS miniport model, this parameter is unused and should be set to 

NULL. The RegistryPath parameter of a PUNICODEJSTRING data type is a path to a 

miniport driver's vendor specific registry key. The key can be used to override default public 

20 symbolic link names and setup optional configuration parameters for the SIAL 251. The 

QueryHandler parameter of W QUERY INFORMATION HANDLER data type is an 

optional function pointer that identifies an internal driver function that is capable of parsing 

standard NDIS Query Information handler calls. A Return Value parameter is returned to the 

SIAL 251. A successful initialization will return a non-zero handle. A initialization failure 

25 will result in a NULL (zero) return value. 
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The SmWdmlfShutdown function destroys an interface created by the public 
function, SmWdmlflnit function and includes the following parameter: 

VOID * SysIfContext 

5 The SysIfContext parameter of VOID pointer data type is the handle returned by the 

public function, SmWdmlflnit function. This parameter is a pointer to the SIAL 251 that is 
being terminated. 

The SmKernelLoadHandlers function queries the SIAL 251 for a driver object 
MajorFunction table and includes the following parameter: 
10 I_0 PDRIVER_OBJECT DriverObject. 

O The DrierObject parameter of PDRIVERJ3BJECT data type is a pointer to a driver 

fi object major function table which is modified to reflect the entry points required for the SIAL 

|| The OS interface 312 supports a limited public set of driver modules. This set is 

f j accessed directly by other SIAL 251 files and is private to all other driver modules. 
LJ A SmWdmlfLoadHandlers function obtains a list of dispatch table entries from the 

public interface module and includes the following parameter: 

IN PDRIVERJDISPATCH * DispatchTable. 

20 The DispatchTable parameter of a PDRIVERJDISPATCH data type enables major 

function points to be added to a dispatch table. 

A SmWdmlfUnLoadHandlers function is used to release any resources that were 
allocated by a previous call to theA SmWdmlfLoadHandlers function and includes the 
following parameter: 
25 IN DEVICE_EXTENSION * pDevExt. 

The pDevExt parameter of a DEVICEJEXTENSION data type is pointer to a device 
extension context used by the SIAL 251. 
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A SmWdmlfSetDeviceParams function is an initialization routine that is called to set 
any device object flags that cannot be set by the platform interface 324. The flags indicate a 
device object is ready to process system requests. The SmWdmlfSetDeviceParams function 
includes the following parameter: 

IN PDEVICEJ3BJECT pDeviceObject. 

The pDeviceObject of PDEVICEJ3BJECT data type is a pointer to device object 
created by the SmWdmlflnit function. 

By employing such a SIAL, software modules and drivers can employ a standard 
interface and thus be interchanged and updated or modified in less time using fewer 
programming resources. In addition, software modules and drivers can be ported to a 
different OS or platform with increased efficiency. 

A chip abstraction layer (ChipAl) is described in a commonly assigned U.S. patent 
application, entitled "CHIP ABSTRACTION LAYER", previously incorporated by 
reference. The system interface abstraction layer and the chip abstraction layer may be 
implemented in a single driver where the hardware abstraction layer is a lower level driver 
and the system interface abstraction layer is an upper level driver. 

The foregoing disclosure and description of the various embodiments are illustrative 
and explanatory thereof, and various changes in the details of the illustrated apparatus and 
construction and method of operation including the number and the order of the processing 
steps may be made without departing from the spirit of the invention. 
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CLAIMS 

We claim: 

1 LA driver system interface, comprising: 

2 an operating system (OS) interface to process a plurality of messages for a plurality of 

3 internal driver entities ; and 

4 a message controller coupled to the OS interface to transfer the plurality messages. 

1 2. The driver system interface of claim 1, further comprising: 

2 a platform interface coupled to the message controller to provide platform specific 
3C3 information to the message controller. 



if i 3. The driver system interface of claim 1, wherein the message controller 

2f i communicates with the OS interface through functions. 

ly 4. The driver system interface of claim 1 , further comprising: 

2 i3 a plurality of message channels to communicate the plurality of messages to and from 

3 the plurality of internal driver entities. 

1 5. The driver system interface of claim 4, the message controller comprising: 

2 a plurality of installable components corresponding to the plurality of message 

3 channels 

1 6. The driver system interface of claim 5, wherein the plurality of installable 

2 components comprise function pointers corresponding to functions in the OS interface. 
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1 7. The driver system interface of claim 1, wherein the message controller routes 

2 the plurality of messages to a plurality of internal entities. 

1 8. The driver system interface of claim 1, the OS interface comprising: 

2 an external interface to communicate with the plurality of external driver entities. 

1 9. The driver system interface of claim 1 ? wherein each message of the plurality 

2 of messages comprises a message header portion containing routing information for the 

3 message controller and a message information portion containing data related to an action for 

4 O a target entity to perform. 

l^T 10. The driver system interface of claim 9, wherein the message header portion 

2?3 comprises an event variable to indicate a unique event for a corresponding message channel 
3Q a message channel identifier variable to indicate the corresponding message channel. 

1 -O 11. A communications driver comprising: 

2 a network driver interface; and 

3 a miniport driver coupled to the network driver interface, the miniport driver 

4 comprising: 

5 a system interface abstraction layer (SIAL) comprising: 

6 an operating system (OS) interface to process a plurality of messages for a plurality of 

7 internal driver entities; and 

8 a message controller coupled to the OS interface to transfer the plurality of messages. 
1 12. The communications driver of claim 1 1 , the SIAL further comprising: 
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2 a platform interface coupled to the message controller for providing platform specific 

3 information and commands to the message controller. 

1 13. The communications driver of claim 11, wherein the message controller 

2 communicates with the OS interface through functions. 

1 14, The communications driver of claim 11, the message controller further 

2 comprising: 

3 a plurality of message channels, each message channel for communicating a subset of 
4P the plurality of messages to and from a corresponding subset of the plurality of internal 
5 1 : devices to a specific external device. 

|g 15. The communications system driver of claim 14, wherein the message 

23 controller comprises a plurality of installable components corresponding to the plurality of 
message channels. 

1 16. The communications system driver of claim 15, wherein the plurality of 

2 installable components comprise function pointers corresponding to functions in the OS 

3 interface. 

1 1 7. The communications driver of claim 1 1 , the OS interface comprising: 

2 an external interface for communicating with the plurality of external entities. 

1 18. The communications system driver of claim 11, the network driver interface 

2 further comprising: 
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3 a dynamic messaging library coupled to the SIAL. 

1 19. The communications system driver of claim 11, wherein each message of the 

2 plurality of messages comprises a message header portion containing routing information for 

3 the message controller and a message information portion containing data related to an action 

4 for a target entity to perform. 

1 20. The communications system driver of claim 19, wherein a message header 

2 comprises an event variable to indicate a unique event for a corresponding message channel 
3D and a message channel identifier variable to indicate the corresponding message channel. 

lj f 21 . A communications card, the communications card comprising: 

2f4 a communications system driver comprising: 

3£3 a network driver interface; 

4 j a miniport driver coupled tot he network driver interface; and 

$0 a system interface abstraction layer (SIAL) coupled to the network 

6 driver interface and the miniport driver, the SIAL comprising: 

7 an operating system (OS) interface for processing a plurality 

8 messages to and from a plurality of entities internal to the OS; and 

9 a message controller coupled to the OS interface for translating 

10 the messages and routing the message to and form an entity external to 

11 the OS. 

1 22 . The communications card of claim 2 1 , the SIAL further comprising : 
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2 a platform interface coupled to the message controller for providing platform specific 

3 information and commands to the message controller. 

1 23. The communications card of claim 21, wherein the message controller 

2 communicates with the OS interface through functions. 

1 24. The communications card of claim 21 , the message controller further 

2 comprising: 

3 a plurality of message channels, each message channel for communicating a subset of 
4Q the plurality of messages to and from a corresponding subset of the plurality of internal 
5p devices to a specific external device. 

ijy 25. The communications card of claim 24, wherein a message header comprises 

2n an event variable to indicate a unique event for a corresponding message channel and a 

1 ; j message channel identifier variable to indicate the corresponding message channel. 

1 26. The communications card of claim 24, wherein the message controller 

2 comprises a plurality of installable components corresponding to the plurality of message 

3 channels. 

1 27. The communications card of claim 26, wherein the plurality of installable 

2 components comprise function pointers corresponding to functions in the OS interface. 

1 28. The communications card of claim 21 , the OS interface comprising: 

2 a external interface for communicating with the plurality of external entities. 
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1 29. The communications card of claim 21, the communications card further 

2 comprising: 

3 a dynamic messaging library coupled to the SIAL. 

1 30. A communications driver, comprising: 

2 a network driver interface; and 

3 a driver system interface comprising: 

4 an external interface to communicate with a plurality of external driver entities; and 
5D an internal interface to communicate with a plurality of internal driver entities. 



f J 31. The communications driver of claim 30, wherein the external interface handles 

j^l the semantics of the plurality of external driver entities. 

£j 32. The communication driver of claim 30, wherein the external interface is a 

20 portion of an operating system (OS) interface. 

1 33. The communication driver of claim 30, wherein the internal interface 

2 comprises a message controller to control a plurality of message channels to pass a plurality 

3 of messages between the plurality of external driver entities and the plurality of internal 

4 driver entities. 

1 34. A method of abstracting a driver system interface, the method comprising the 

2 steps of: 
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3 creating a platform specific and operating system specific message channel between 

4 an internal driver entity and an external driver entity; and 

5 routing a software message between the internal driver entity and the external driver 

6 entity through the platform specific and operating specific message channel. 

1 35. The method of claim 34 y further comprising the steps of: 

2 creating a plurality of platform specific and operating specific message channels 

3 between a plurality of internal driver entities and a plurality of external driver entities; and 

4 routing a plurality of software messages between the plurality of internal driver 
fo entities and the plurality of external driver entities. 

lp 36. The method of claim 34, further comprising the steps of: 

4 L] creating a platform specific and operating specific message channel between a first 

3H internal driver entity and a second internal driver entity; and 

47§ routing a software message between the first driver entity and the second driver entity 

5o through the platform specific and operating system specific message channel. 

1 37. The method of claim 34, wherein the routing step is performed by an 

2 installable component corresponding to the message channel. 

1 38. The method of claim 34, wherein the software message comprises a header 

2 portion containing routing information and an information portion containing data specific to 

3 an action to be performed by a target driver entity. 
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39. The method of claim 34, wherein the internal driver entity is a miniport driver 
module and the external driver entity is a non-miniport driver module. 
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ABSTRACT 

A communications card provides a miniport driver including a system interface 
abstraction layer (SIAL) that eliminates operating system (OS) specific and platform specific 
semantics from communication paths between a driver and the rest of the communications 
system. The SIAL provides a layer of software that connects an unspecified number of 
messaging channels to a single interface. The SIAL provides a message controller that is 
responsible for routing messages between various internal and external entities and contains 
multiple installable components, an operating system component which provides OS 
functions for the installable components and a platform module that supplies platform 
specific functions to the installable components. 
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Figure 1 
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